Skip to content

Conversation

KrxGu
Copy link
Contributor

@KrxGu KrxGu commented Oct 7, 2025

This adds a positive semantics test showing that:

  • A named COMMON block in a clause is equivalent to listing all explicit members.
  • The same list item may appear in both firstprivate and lastprivate on the same construct.

The reporter example in #162033 therefore conforms to OpenMP and Flang is correct to accept it. This test documents and locks in that behavior to avoid regressions.
image

@KrxGu
Copy link
Contributor Author

KrxGu commented Oct 12, 2025

@tblah didn't knew who to tag so tagged you(as related to flang just like the one you merged earlier), this PR is waiting to be reviewed and CI is all green and good to merge!!

@@ -0,0 +1,13 @@
! RUN: %flang_fc1 -fopenmp -fsyntax-only %s 2>&1 | FileCheck %s --allow-empty
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please could you add -fopenmp-version=60 (or whichever version was the first to allow this) so that this test does not fail once the required check is added for older openmp versions.

@@ -0,0 +1,13 @@
! RUN: %flang_fc1 -fopenmp -fsyntax-only %s 2>&1 | FileCheck %s --allow-empty
! CHECK-NOT: error:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please could you add a short comment explaining that this is a regression test to ensure this is allowed in newer openmp versions

@KrxGu KrxGu force-pushed the flang-omp-common-fp-lp-test branch from a6d387e to 36e9310 Compare October 15, 2025 19:45
@llvmbot llvmbot added flang Flang issues not falling into any other category flang:openmp flang:semantics labels Oct 15, 2025
@llvmbot
Copy link
Member

llvmbot commented Oct 15, 2025

@llvm/pr-subscribers-flang-semantics

@llvm/pr-subscribers-flang-openmp

Author: Krish Gupta (KrxGu)

Changes

This adds a positive semantics test showing that:

  • A named COMMON block in a clause is equivalent to listing all explicit members.
  • The same list item may appear in both firstprivate and lastprivate on the same construct.

The reporter example in #162033 therefore conforms to OpenMP and Flang is correct to accept it. This test documents and locks in that behavior to avoid regressions.
<img width="1606" height="350" alt="image" src="https://github.com/user-attachments/assets/0b464c58-b9cc-43e0-8d1f-1c5a5b993bf6" />


Full diff: https://github.com/llvm/llvm-project/pull/162234.diff

1 Files Affected:

  • (added) flang/test/Semantics/OpenMP/omp-common-fp-lp.f90 (+21)
diff --git a/flang/test/Semantics/OpenMP/omp-common-fp-lp.f90 b/flang/test/Semantics/OpenMP/omp-common-fp-lp.f90
new file mode 100644
index 0000000000000..ed52e76ca62ce
--- /dev/null
+++ b/flang/test/Semantics/OpenMP/omp-common-fp-lp.f90
@@ -0,0 +1,21 @@
+! RUN: %flang_fc1 -fopenmp -fopenmp-version=51 -fsyntax-only %s 2>&1 | FileCheck %s --allow-empty
+! CHECK-NOT: error:
+! CHECK-NOT: warning:
+
+! Regression test for issue #162033.
+! Verify that a named COMMON block can appear in a data-sharing clause together
+! with one of its members in another clause on the same construct. This is valid
+! in OpenMP >= 5.1 because:
+!  - A named COMMON in a clause is equivalent to listing all its explicit members
+!  - A list item may appear in both FIRSTPRIVATE and LASTPRIVATE on the same directive
+! OpenMP 5.0 explicitly forbade this combination.
+
+subroutine sub1()
+  common /com/ j
+  j = 10
+!$omp parallel do firstprivate(j) lastprivate(/com/)
+  do i = 1, 10
+     j = j + 1
+  end do
+!$omp end parallel do
+end

@KrxGu KrxGu force-pushed the flang-omp-common-fp-lp-test branch from 36e9310 to 346c4c0 Compare October 15, 2025 20:05
…tprivate is valid

Gate test to OpenMP 5.1+ and add explanatory comment per review feedback.
@KrxGu KrxGu force-pushed the flang-omp-common-fp-lp-test branch from 346c4c0 to 7d0ee79 Compare October 15, 2025 21:38
@KrxGu
Copy link
Contributor Author

KrxGu commented Oct 15, 2025

@tblah Thanks for the review! I've addressed both comments:

  1. Added -fopenmp-version=51 to gate the test to OpenMP 5.1+
  2. Added an explanatory comment documenting this as a regression test for [Flang][OpenMP] No error checking when specifying named common block in LASTPRIVATE clause of the PARALLEL DO construct and its member in FIRSTPRIVATE clause of the same construct #162033

Note on CI fix: I also removed the CHECK-NOT: warning: line because Flang emits an informational warning about incomplete OpenMP 5.1 support. The test still validates that no semantic errors occur via CHECK-NOT: error:.

CI is all green, good to merge!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

flang:openmp flang:semantics flang Flang issues not falling into any other category

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants